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Abstract 

Rapid  prototyping  and  tool  reusability  have  pushed  knowledge  acquisition  research  to  investi¬ 
gate  niethod-speciGc  knowledge  acquisition  tools  appropriate  for  predeterniined  problem-solving 
methods.  We  believe  that  method-dependent  knowledge  acquisition  is  not  the  only  approach.  The 
aim  of  our  research  is  to  develop  powerful  yet  versatile  machine  learning  mechanisms  that  can 
be  incorporated  into  general-purpose  but  practical  knowledge  acquisition  tools.  This  paper  shows 
through  examples  the  practical  advantages  of  this  approach.  In  particular,  we  illustrate  how  existing 
knowledge  can  be  used  to  facilitate  knowledge  acquisition  through  '  Jialogy  mechanisms  within  a 
domain  and  across  domains.  Our  sample  knowledge  acquisition  aialogues  with  a  domain  expert 
illustrate  which  parts  of  the  process  are  addressed  by  tiie  human  and  which  parts  arc  automated 
by  the  tool,  in  a  synergistic  cooperation  for  knowledge-base  extension  and  refinement  The  paper 
also  describes  briefly  the  expect  problem-solving  architecture  that  facilitates  this  approach  to 
knowledge  acquisition. 

Keywords:  knowledge  acquisition;  knowledge-base  refinement;  learning  by  analogy;  expla- 


1  Introduction 


The  science  of  artificial  intelligence  started  with  and  continues  to  build  on  general  principles. 
Newell  and  Simon’s  pioneering  work  on  understanding  human  problem  solving  shows  us  that  the 
same  mechanisms  come  to  play  when  trying  to  find  solutions  to  problems  that  may  seem  very 
different  [Newell  and  Simon,  1972}.  GPS  implemented  this  principle  and  demonstrated  that,  given 
domain-specific  knowledge,  a  general-purpose  reasoning  engine  can  be  used  to  solve  problems 
in  that  specific  domain,  and  that  the  same  engine  can  be  used  for  different  problem-solving 
applications.  Decades  later,  a  constellation  of  expert  systems  was  possible  thanks  to  the  expert 
.system  shell  version  of  GPS  (e.g.,  (Buchanan  and  Shortliffe,  1984]).  Inference  is  understood,  .said 
common  AI  wisdosn,  the  hard  pari  is  getting  the  knowledge  right.  General-purpose  inference 
mechanisms,  general-purpo.sc  representation  mechanisms  (a  similar  argument  can  be  shown  with 
Minsky’s  frames  for  the  field  of  knowledge  repre.sentalion)  gave  AI,  like  any  other  science,  the 
beauty  of  building  on  principles.  Re.scarchers  turned  then  to  the  next  i.ssue  in  the  automated 
reasoning  agenda:  machine  learning  and  the  acquisition  of  knowledge.  The  work  ranges  from 
learning  heuri.stic  knowledge  [Mintcin,  1988;  Knoblock,  199.^1  to  acquiring  factual  knowledge 
[Gil,  1992],  and  shows  us  that  complete  automation  of  the  learning  or  acquisition  task  in  domains 
of  technical  cx(x:rti.sc  is  far  from  reach.  Semi-automated  general-purpo.se  knowledge  acquisition 
(KA)  tools  [Davis,  1980]  are  not  enough  to  achieve  efficient  prototyping.  Generality  docs  not 
provide  the  tool  with  much  basis  to  support  the  knowledge  engineering  process. 

At  the  .same  time,  we  witnessed  the  surge  of  special-purpose  mechanisms  to  support  real- 
world  applications.  General-purpose  tools  seemed  incapable  of  performing  well  in  applications 
such  as  manufacturing  or  robot  path  planning  [Lozano-Pcrc/.,  1987;  Chang  and  Wysk,  I98.'i|. 
The  new  ctimmon  AI  wisdom  reflects  that  general-purpose  is  good,  but  may  not  be  enough  us 
wo  currently  understand  it.  The  field  of  knowledge  acquisition  has  rightly  taken  this  lesson. 
Genera- -purpo.se  KA  tools  are  augmented  with  application-mdcpi.ndent  mctlnxl-spccitic  inference 
structures  |Chandra.sckaran.  1 98b;  McDermott.  1 988].  For  example.  .SALT  |  Marcus  and  McDermott, 
1989)  proviucs  support  for  propose-and-revise  tasks.  PRtvna'ili  [Musen,  1989]  helps  in  acquiring 
knowledge  in  temporal  skeletal  planning  applications.  Although  the  resulting  tools  have  less 
generality,  they  allow  the  semi -automated  production  of  fast  prototyjKs  in  novel  diunains  once 
the  appropriate  inference  mechanism  is  manually  determined.  The  inference  mechanisms  provide 
expectations  about  the  role  of  each  piece  of  knowledge  that  are  powerful  guidance  in  the  knowledge 
acquisition  proce.ss. 

However,  this  approach  to  building  KA  toois  has  limitations  that  ari.se  from  the  need  of  more 
flexibil  ity  than  they  provide  in  adapting  them  to  an  application  j  Musen,  1 992  ] .  The  problem-.sol ving 
structure  of  an  application  cannot  always  be  defined  in  domain-independent  terms.  Furthermore, 
these  method-specific  inference  mechanisms  may  not  address  some  of  the  particulars  of  an  ap¬ 
plication  simply  bccau.se  they  were  designed  with  generality  in  mind.  Another  problem  with 
the  method-specific  KA  tools  is  that  they  raise  the  non  trivial  issue  of  determining  a  library  of 
possible  methods  |Chandra.sckaran,  1986;  McDermott,  1988).  The  work  involves  handcrafting 
this  library  of  methods  making  sure  to  provide  both  wide  coverage  of  tasks  and  well-understood 
characterizations  of  the  inference  capabilities  of  each  method. 

To  address  these  limitations,  some  researchers  [Klinker  et  al.,  1991;  Puerta  ei  al.,  1992]  are 
developing  libraries  of  problem-solving  mcthrids  that  handle  finer-grained  inference  structures  than 
the  ones  above.  Thc.se  approaches  provide  much  more  llexibility  in  building  a  knowledge-based 


system  but  two  major  issues  remain.  One  is  the  task  of  building  method  libraries.  Another  issue  is 
the  accessibility  of  KA  tools  to  domain  experts.  The  users  of  these  tools  still  need  to  be  knowledge 
engineers  [Kitto,  1988]. 

The  goal  of  the  EXPECT  project  is  to  provide  an  environment  for  the  development  of  knowledge- 
based  systems  that  aids  in  the  acquisition,  maintenance,  and  documentation  of  the  knowledge  about 
a  task.  Our  KA  tool  is  independent  of  the  inference  structure  or  problem-solving  method  of  the 
task.  This  paper  concentrates  on  EXPECT  as  a  tool  for  knowledge  refinement  and  describes  our 
work  on  how  to  correct  and  extend  an  existing  knowledge  base.  Our  tool  uses  machine  learning 
techniques  to  support  knowledge  refinement  independently  of  the  inference  structure  of  the  task. 
Our  KA  work  focuses  on  the  integration  of  machine  learning  methods  in  KA  tools  that  can 
automatically  (or  semi-automatically)  come  up  with  generalized  versions  of  methods  that  express 
domain-specific  inference  structures  and  .support  their  reuse  in  new  domains  and  new  .situations 
through  analogy.  Thispapershowsour  first  results  in  this  direction  and  illu.strates  through  examples 
the  practical  advantages  of  this  approach.  In  particular,  we  show  how  EXPECT  currently  uses  the 
same  general-purpose  mechanism  (analogy)  to  support  knowledge  refinement  within  a  domain 
and  across  domains.  Tiie  system  and  the  user  work  in  synergy:  unlike  other  machine  learning 
approaches,  ou.-  system  does  not  attempt  to  deduce  all  the  information  needed  to  form  an  analogy 
by  itself.  Rather,  it  relies  on  input  from  the  user  to  guide  its  analogical  learning.  On  the  other 
hand,  the  u.ser  does  not  need  to  know  a  lot  about  the  knowledge  ba.se  or  enter  all  the  new  necessary 
knowledge  explicitly,  but  can  rely  on  the  tool  to  guide  the  knowledge  acquisition  process. 

The  issue  of  accessibility  to  domain  experts  has  been  central  in  the  design  of  our  architecture 
(Nechesetu/..  198.*i;  Swartouteto/.,  199l;SwartoutandSmoliar,  1987).  The  explicit  representation 
of  factual  and  problem-solving  knowledge  and  the  ability  to  produce  flexible  explanations  in  an 
interactive  dialogue  provide  the  basis  for  building  a  KA  tool  that  communicates  with  an  expert 
much  in  the  way  a  colleague  in  their  field  of  expertise  would.  Our  work  in  this  area  is  not  the  main 
focus  of  this  paper,  and  it  is  discus.sed  elsewhere  [Paris  and  Gil,  199.'^;  Moore  and  Paris,  In  press). 

The  examples  throughout  the  paper  are  from  a  logistics  transportation  application  that  evaluates 
proposed  routings,  taking  into  account  restrictions  on  objects  transported,  destination  points,  and 
vehicles  used.  U.sers  are  specialists  in  sea  transjxirtalion  planning.  EXPECT  is  given  knowledge 
about  ships,  seaports,  packages,  berths,  etc.,  as  well  as  plans  for  tran.sporting  objects.  U.sers  arc 
interested  in  c.stimating  how  long  it  lakes  to  transport  .some  number  of  objects  from  one  location  to 
another  with  the  resources  available. 

The  paper  runs  as  follows.  We  first  describe  briefly  our  problem-.solving  architecture  and  our 
knowledge  rcpre.sentation  language.  Then  we  illustrate  how  EXPECT  makes  use  of  analogy  to 
facilitate  KA  within  a  domain  and  across  domains.  Later,  we  describe  our  plans  for  future  work 
through  an  example  .scenario  that  uses  the  same  analogy  techniques  augmented  with  generalization 
to  facilitate  KA  in  a  different  domain.  Our  scenarios  illu.sirate  the  u.ser's  involvement  during 
knowledge  acquisition,  as  well  as  which  parts  of  the  process  are  automated  by  the  tool. 

2  The  EXPECT  Architecture 

EXPECT  builds  upon  previous  work  on  the  Explainable  Expert  System  (EES)  framework  [Neches  et 
al.,  1985;  Swartout  ef  a/.,  1991 ;  Swartout  and  Smoliar,  1987],  which  allows  for  the  construction  of 
expert  .systems  that  can  provide  good  '  ural  language  explanations  of  their  behavior  [Moore  and 


l-'ipurc  I :  A  schematic  representation  of  l-XPl-CT.  The  design  history  and  the  knowledge  base 
components  are  used  to  form  expectations  for  knowledge  acquisition. 


Paris,  In  pre.ss;  Moore,  1989;  Moore  and  Swartout,  1989;  Moore  and  Swartout,  1991].  EXPECT’s 
architecture  ts  shown  in  Figure  I .  In  EXPECT,  different  kinds  of  knowledge  are  specified  in  distinct 
knowledge  ba.ses  in  a  high-level  specification  language.  The  specific  actions  that  are  to  be  executed 
by  the  system  to  .solve  a  specific  problem  are  derived  from  these  knowledge  bases  by  the  system, 
and  a  record  of  the  derivation  is  .stored  to  provide  the  rationale  for  the.se  actions.  The  knowledge 
acquisition  tool  u.ses  this  rationale  and  the  knowledge  ba.ses  themselves  to  form  expectations  to 
support  the  interaction  with  the  user  A  natural  language  generation  module  produces  justifications 
and  explanations  of  the  systeni’s  behavior  to  the  user. 

The  knowledge  bases  capture  what  the  system  knows  about  the  domain  and  how  to  solve 
problems  in  that  domain.  They  comprise: 

•  A  domain  descriptive  knowledge  base  (or  domain  model),  which  stores  definitions  and  facts 
in  the  task  domain.  The  domain  model  is  written  in  LOOM  [MacGregor,  1988;  MacGregor, 
1991],  a  knowledge  representation  formalism  of  the  KL-ONE  family.  LOOM  uses  a  descriptive 
logic  representation  language,  and  includes  a  classifier  for  inference. 

•  A  problem-solving  knowledge  base,  which  contains  an  organized  collection  of  plans.  A  plan 
in  EXPECT  is  an  abstract  and  generic  description  of  how  a  goal  can  be  achieved,  instead  of  a 
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sequence  of  operators  [Hikes  and  Nilsson,  1971].  The  plan  language  allows  for  an  expiicii 
representation  of  intent  (what  is  to  be  done  to  achieve  a  goal)  and  supports  a  wide  range  of 
control  structures  to  combine  subgoals  (e.g.,  conditionals,  variable  assignments,  iteration). 

As  an  example,  consider  Figures  2  and  3,  which  contain  samples  of  these  knowledge  bases  for 
the  logistics  transpiortation  domain.  In  that  application,  the  domain  model  includes  descriptions  of 
ports,  seaports,  and  airports.  The  representation  of  a  seaport  is  shown  in  Figure  2: 
A  seaport  is  a  type  of  port,  and  it  has  attributes  such  as  the  ships  available  at  the  seaport,  its 
piers,  its  benhs,  and  the  available  storage  areas.' 

Figure  3  shows  two  very  simple  plans  of  the  problem-solving  knowledge  base.  The  capability 
describes  the  goals  that  the  plan  can  achieve,  the  method  represents  the  body  of  the  plan,  and 
the  result  type  indicates  what  is  returned  by  the  method.  The  first  plan  can  be  used  to  determine 
whether  a  specific  type  of  ship  is  supported  (or  “fits  in”)  a  given  seaport.  This  is  done  by  testing 
whether  the  length  of  the  ship  is  less  than  the  maximum  vessel  length  allowed  in  that  particular 
seaport.  The  second  plan  finds  the  maximum  ship  length  a  seaport  supports  based  on  the  length  of 
its  berths. 

Given  a  high-level  goal,  a  Program  Writer  integrates  these  structured  knowledge  bases  by 
refinement  and  reformulation  from  that  goal  [Nechesern/.,  1985;  Swartoui  e/a/.,  1991]  to  produce 
a  system  that  will  be  capable  of  solving  specific  instances  of  that  goal.  The  goal  is  matched  against 
the  problem-solving  knowledge  base.  The  method  of  the  plan  found  causes  additional  subgoals  to 
be  posted,  and  the  process  is  iterated.  EXPECT’s  matcher  unifies  goals  and  plans  according  to  the 
.semantic  representation  of  the  goal’s  arguments.  For  example,  a  goal  to  find  the  distance  between 
two  cities  matches  a  plan  to  find  the  distance  between  two  locations,  since  cities  are  locations.  Type 
constraints  are  also  propagated  through  the  method  of  plans.  The  Program  Writer  also  reformulates 
goals  when  no  plan  is  found  to  match  them. 

The  Program  Writer  records  all  its  steps  and  decisions  in  an  annotated  design  history.  For 
example,  Figure  4  shows  the  most  relevant  parts  of  the  design  history  for  the  general  goal  to 
transport  a  set  of  objects  to  a  location  using  a  set  of  ships.  The  design  history  reflects  both 
the  goal/subgoal  expansion  as  well  as  some  goal  reformulations.  For  example,  the  subgoal 
determine-whether-f  its-in  was  reformulated  into  three  goals,  one  for  each  type  of 
ship  that  the  system  knows  of,  as  indicated  in  the  domain  model. 

The  design  history  tells  the  system  whether  a  definition  is  used  and  where,  what  it  is  used  for, 
and  how.  The  system  understands  that  the  type  of  a  ship  will  require  taking  a  different  path  in  the 
tree,  because  there  are  different  procedures  to  detennine  if  a  ship  fits  in  a  seaport  depending  on  what 
type  of  ship  it  is.  The  same  can  be  said  about  each  plan:  the  design  history  records  whether  they  are 
used  and  where,  for  what  goals,  and  with  what  arguments.  In  essence,  it  represents  the  functionality 
of  the  knowledge  that  the  domain  model  contains.  It  thus  allows  the  system  to  reason  about  how 
knowledge  will  be  used.  This  is  crucial  as  one  cannot  indiscriminately  add  new  knowledge  into 
a  system  but  rather  needs  to  understand  how  that  knowledge  will  be  used.  Otherwise,  there  is  a 
danger  that  the  knowledge  added  be  useless  or  incomplete  to  achieve  the  task  for  which  the  system 
is  designed.  The  design  history  also  provides  an  important  piece  of  information:  what  knowledge 
is  not  used  for  problem  solving.  The  .system  is  aware  of  what  plans  are  not  being  matched  with 
any  goals  and  which  parts  of  the  domain  model  are  not  currently  relevant  for  the  task.  These  are 
signs  that  the  user  needs  to  correct  the  system’s  current  knowledge  to  make  all  of  it  useful  for  the 


'We  use  the  prefix  “r-"  to  indicate  names  of  relations. 


(def concept  seaport 
:is  (:and  port 

{:some  r-ships  ship) 

( : some  r-berths  berth) 

(:some  r-piers  number) 

( : some  r -covered-storage-area  number))) 


Figure  2:  Definition  of  a  seaport  in  the  domain  model. 


(def ine-plan  FIND- IF-SHIP-FITS- IN- SEAPORT 

:eapability  (determine-whether-f its-in (OBJ  (?s  is  (inst-o£  ship))) 

(IN  ( ?p  is  (inst-of  seaport)))) 

; result-type  boolean 

;raethod  (less-than  (r-ship-length  ?s) 

(compute-max-vessel-length-in-seaport  ?p) ) ) 


(def ine-plan  COMPUTE-MAX-VESSEL-LENGTH- IN-SEAPORT 
: capability  (compute -max- vessel -length- in- seaport 

(OBJ  (?s  is  (inst-of  seaport)))) 

: result-type  number 

;metliod  (let  ( ( ?berth-types  (r-berth-type  (r-berth-availability  ?s)))) 
(max  ( r-berth-length  ?ber th- types) )) ) 


Figure  3:  Two  plans  from  the  transportation  domain. 


task  at  hand.  The  scenarios  in  the  next  sections  illustrate  in  more  detail  how  these  features  of  the 
architecture  support  knowledge  acquisition. 

Figure  5  shows  EXPECr’s  user  interface.  The  user  can  examine  the  current  contents  of  knowledge 
bases  by  pulling  menus  and  choosing  to  display  the  concept  hierarchy  or  the  design  history.  When 
the  user  clicks  on  a  concept,  the  system  provides  a  description  of  what  is  currently  known  about 
it.  The  user  can  also  examine  instances.  When  the  user  clicks  on  a  node  in  the  design  history,  the 
system  describes  in  detail  both  what  goal  is  accomplished  in  a  node  and  how  (a  reformulation,  a 
grammar  construct,  a  plan).  The  user  can  also  look  up  plans  from  the  problem-solving  knowledge 
base.  In  short,  the  interface  allows  the  user  to  inspect  the  knowledge  currently  available  to  the 
system,  which  is  the  first  step  toward  detecting  errors  that  can  be  corrected  through  knowledge 
acquisition. 

When  the  user  detects  a  knowledge  fault  through  this  inspection  process,  the  interface  offers 
several  possibilities  to  change  the  contents  of  the  knowledge  bases,  and  at  different  levels  of 
detail.  The  user  can  change  existing  information  about  instances  or  add  new  instances  (e.g.,  new 
locations,  new  seaports).  The  user  can  also  change  any  plan  by  manipulating  its  components 


calculaic-iinic-to-lransporl-objccts  i  )bjs.loc  1  ,loc2) 


calculaie-total-cargo-wcijhl  (objs)  calculatc-liinc-lo-iransport-cargo(weighl.locl.loc2) 


liiid  ships-io-iravcl  (locl.loe2) 

calc-jlale-lime-io-tranipon-in-ship  ('vcighi,ship,locl,loc2) 


find-scaport-of-locaiion  (loci) 

find  sb ips-avai labic-on-scaport  (port) 

deicrmine-whclher-fiis-in  (pon.ships) 


hnd-dislancc(locl.loc2)  lind-spced(ship) 


dctcmiine-tt'ciher-fits-in  (pon.  brcakbulk) 


re/ormiilniiuri 


dcicmiine-wciher-fus  in  (pon.  container) 


dclerniinc-wether-fiis-in  (pun. lash) 


computc-max-vcssel-lengih-in-seapori  (port) 


Figure  4;  Relevant  portions  of  the  design  history  produced  by  the  problem  solver. 


(adding,  removing,  or  substituting  substeps),  or  add  new  plans  either  created  by  the  user  or  created 
by  the  system  by  analogy  with  existing  plans.  Finally,  the  user  can  change  portions  of  the  design 
history  by  manipulating  its  nodes.  Adding  or  removing  a  step  in  a  node  causes  the  plan  in  that  node 
to  be  changed,  as  well  as  any  plans  that  appear  in  the  subtree  originating  at  that  node.  If  any  new 
subgoals  cannot  be  matched  with  existing  plans,  the  system  creates  new  plans  by  analogy  with  the 
plans  in  the  original  subtree.  The  next  section  shows  an  example  of  this  behavior. 


3  Transfer  of  Problem-Solving  Knowledge  Within  a  Domain 

Figure  6  shows  a  scenario  in  which  existing  problem-solving  knowledge  is  corrected.  The  user 
is  presented  with  menus  (instead  of  being  allowed  to  type  in  free  English),  but  we  paraphrase 
here  the  user’s  intervention  in  English  for  clarity  and  indicate  this  with  italics.  EXPECT  generates 
language  descriptions  of  plans  of  the  type  shown  in  this  figure  and  carries  out  the  modifications  to 
its  knowledge  base  as  indicated  by  the  user. 

In  this  scenario,  the  system  is  given  the  problem  of  transporting  a  unit  to  the  seaport  of  Cabra 
(line  1 1 1).  The  system  solves  the  problem  and  reaches  the  conclusion  that  it  takes  3  days  (line  [2]). 
The  user  is  surprised  that  it  could  be  done  so  fast  in  such  a  small  seaport  and  asks  why  (line  [3]). 
The  system  explains  its  conclusion  by  retracing  its  reasoning  (line  [4]).  Notice  that,  at  this  point. 


Figure  5:  liXI'liCT’.s  user  interface 


only  a  summary  of  the  whole  reasoning  is  included  in  the  explanation,  thus  pioviilmg  a  high  level 
justification  for  the  conclusion.  The  user  can  however  “zoom-in"  on  particular  part  ol  the  piohleiii 
solving  by  asking  further  questions.  This  is  illustrated  in  lines  l-'t-b]. 

The  justifications  provided  by  the  sy.stcin  allow  the  user  to  detect  a  potential  eiioi  the  usei 
disagrees  with  some  of  the  information  given  by  the  system  and  provides  conflicting  infoiiiiation 
(line  [7]).  Given  this  new  information,  F.XPfiCT  now  reasons  about  the  design  history  to  |o<Mli/e 
the  problem,  and  a  dialogue  to  debug  the  system  is  initiated. 

First,  EXPECT  finds  the  exact  place  in  the  design  history  that  led  to  the  conclusion  <|uestioned 
by  the  user  and  explains  that  part  of  the  rea.soning  (line  18]).  This  allows  the  user  to  detect  the 
problem  more  precisely.  In  this  case,  the  user  realizes  that  the  plan  to  determine  witcthei  a  sliij’  fils 
in  a  port  is  incorrect  (or  incomplete).  The  user  thus  provides  the  additional  information,  iiamciv 
that  the  draft  of  a  ship  must  also  be  taken  into  consideration  (line  (9))  at  a  particular  node  of  the 
design  history.  The  system  asks  the  u.ser  how  to  check  the  draft,  and  whclitcr  the  analogy  witli 
checking  the  length  is  appropriate.  This  is  possible  because  the  system  already  has  a  plan  to  check 
the  length,  and  it  can  use  it  to  form  an  expectation  for  how  to  check  the  draft  (line  1 10)).  Upon 
positive  reaction  (line  ( 1 1  ]),EXPECTprepares  the  elements  that  can  Ik  the  source  of  the  analogy,  iind 
prompts  the  user  for  their  correspondents  (line  [12]).  After  the  u.scr’s  response  (line  1 1 .1)),  iXPlfl 
summarizes  to  the  user  the  changes  made  to  the  knowledge  base  (line  I  Mil.  Notice  tlial  since  the 


U :  How  long  does  it  take  to  transport  that  unit  to  Cabra  with  the  ships  available  7  [  1  ] 

S:  3  days  12] 

U:  Why?  [3] 

■S:  To  iraiiftpnrt  unit  X  to  a  location,  first  I  calculated  that  the  total  weight  of  the  [4] 

cargo  is  30(),fXX]  tons,  then  1  determined  that  I  could  use  3  container  ships  and 
10  hreakhulk,  and  distributed  the  cargo  among  the  ships. 

U:  Why  brrtikitulk  ships  7  [5] 

S:  I  used  the  Cabra  seaport,  and  determined  that  breakbulk  ships  fit  in  the  Cabra  [6] 

seaport. 

1 1:  7  his  Is  wrong.  Cahra  is  too  smalt  for  breakbulk  ships.  [7] 

.S:  I  roncliided  that  hreakhulk  ships  fit  in  the  Cabra  seaport.  To  do  this,  I  checked  (8) 

that  the  ship  length  is  less  than  the  maximum  vessel  length  in  that  seaport.  Is 
till*  right  /  (Yes;  No;  Yes  with  constraints) 

l.l,  )ir.i,  with  constraints:  you  have  to  check  both  the  length  and  the  draft.  [9] 

.S:  I  know  how  to  check  the  length.  Do  I  check  the  draft  in  a  similar  way?  (Yes;  [10] 

No;  Yes  with  constraints) 

U.  yes  [11] 

.S  WInii  corrcs|>onds  to  ( I )  the  ship  length  (2)  less  than  (3)  the  maximum  vessel  [  1 2] 

length  in  thill  seaport? 

U :  (!)  ship  draft  (2 )  les s  than  (.1)  maximum  vessel  draft  in  the  seaport  [13] 

,S  (Jk,  , So  to  determine  what  ship  ly|)cs  lit  in  a  .seaport,  I  determine  if  the  ship  [14] 


length  i^  less  than  the  maximum  vessel  length  in  that  seaport,  and  then  I 
dririmine  if  the  ship  draft  is  less  than  the  maximum  vessel  draft  allowed  in 
the  scup<in.  Uolh  hove  to  Ik  true  in  order  for  a  ship  type  to  fit  in  a  seaport. 

CoireciV  (Yes  or  No) 

U  >'ej  [15] 

(...1 

b  Ke-solvlng  the  problem  with  the  updated  method  for  determining  what  ship  [16] 

tyjKs  lit  III  n  scoporl.  It  lakes  10  days  to  transport  the  unit  to  Cabra. 


I-igurcO:  lixamplc  .scenario;  Modifying  existing  plans. 


iCMilix  ul  lioili  checks  lire  boolean,  the  .sy.stcm  also  has  a  suggestion  about  how  to  combine  them. 
The  plan  Is  now  corrected,  After  the  problem  has  been  fixed,  EXPECT  re-works  the  original  goal 
(line  I  U)|)  Notice  that  since  the  system  did  not  find  a  plan  to  compute  the  maximum  vessel  depth 
on  a  snijMiii,  it  created  a  new  plan  by  analogy  with  tlic  plan  that  achieves  the  goal  of  computing 
the  niaxiniiiiii  vessel  length.  The  acquisition  of  this  new  plan  is  done  autonomously  by  the  system, 
based  on  the  user's  suggested  change.i  on  how  the  problem  was  solved.  This  is  possible  because 
the  design  history  rellccls  the  fact  Ihul  this  plan  i.s  used  in  the  part  of  the  reasoning  that  the  user 
wants  to  nuKllfy.  If  the  new  plan  hud  any  inconsi.slcncics,  l-XPEcr  would  notify  the  user.  This  can 


S: 

[1] 

U; 

To  service  a  type  of  aircraft,  first  check  if  it  fits  in  a  hangar.  Similar  to  how  a 
ship  fits  in  a  seaport. 

[2] 

i 

S: 

To  determine  what  ship  types  fit  in  a  seaport,  1  determine  if  the  ship  length  is 
less  than  the  maximum  vessel  length  in  that  seaport,  and  then  I  determine  if  the 
ship  draft  is  less  than  the  maximum  vessel  draft  allowed  in  the  seaport.  Both 
have  to  be  true  in  order  for  a  ship  type  to  fit  in  a  seaport.  We  want  to  describe  a 
way  to  determine  if  a  type  of  aircraft  fits  in  a  hangar.  What  co.responds  to  (1) 
the  ship  length  (2)  less  than  (3)  the  maximum  vessel  length  in  that  seaport  (4) 
the  ship  draft  (5)  less  than  (6)  the  maximum  vessel  draft  allowed  in  the  seaport 
(7)  both  have  to  be  tme? 

[3] 

« 

U: 

(/)  aircraft  length  (2)  less  than  (3)  hangar  length  (4)  aircraft  height  (5)  less 
than  (6)  hangar  height  (7)  both  have  to  be  true. 

14] 

• 

S: 

Ok.  So  in  order  to  check  if  a  type  of  aircraft  fits  in  the  hangar,  I  determine  if 
the  aircraft  length  is  less  than  the  hangar  length,  and  then  1  determine  if  the 
aircraft  height  is  less  than  the  hangar  height.  Both  have  to  be  true  in  order  for 
an  aircraft  type  to  fit  in  the  hangar.  [Yes;  No;  Yes  with  constraints] 

[5] 

• 

U: 

Yes,  with  constraints:  you  have  to  check  length,  height,  and  width. 

[6] 

S: 

Ok.  I  know  the  length,  width,  and  height  of  hangars.  I  know  the  length  and 
height  of  an  aircraft.  What  is  the  width  of  an  aircraft? 

[7] 

U: 

Wing  span  7 

[8] 

S; 

1  understand.  I  know  how  to  check  the  length  and  the  height.  Do  I  check  the 
width  in  a  similar  way?  (Yes;  No;  Yes  with  constraints) 

[9] 

• 

U: 

Yes 

[10] 

S: 

Ok.  So  in  order  to  check  if  a  type  of  aircraft  fits  in  a  hangar . . . 

Figure  7:  Example  scenario:  Adding  new  plans. 

[11] 

• 

be  caused  by  incompletenesses  in  the  mapping  that  the  user  gives  the  system  to  do  the  analogy.  It  is 
important  to  realize  that  had  the  system  found  an  existing  plan  to  solve  the  new  goal,  it  would  have 
used  this  plan  to  expand  the  new  subtree.  EXPECT  is  acquiring  new  plans  for  its  problem-solving 
knowledge  base,  effectively  learning  at  the  knowledge  level  [Newell,  1982]. 

Figure  7  shows  a  different  scenario  where  new  plans  are  added  to  the  knowledge  base  by  the 
user.  Much  like  in  the  previous  scenario,  the  user  communicates  to  the  system  the  analogy  of  ships 
and  ports  with  aircrafts  and  hangars:  what  to  retrieve  (line  [2]),  what  the  correspondences  are  (line 
[4J),  and  what  the  exceptions  are  (lines  [6-10]).  The  system  takes  charge  of  the  rest,  including 
updating  the  corresponding  parts  of  the  different  knowledge  sources. 

4  Transfer  of  Problem-Solving  Knowledge  Across  Domains 

The  analogies  in  the  above  scenarios  involve  plans  within  the  same  domain,  but  exactly  the  same 
mechanism  applies  if  the  new  plans  are  in  a  different  domain.  For  example,  the  user  can  suggest 
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Ihe  similarities  with  checking  if  a  package  fits  in  a  trxick.  or  if  any  physical  object  fits  in  another. 
Because  the  analogy  is  not  worked  out  automatically  and  the  user  is  in  charge  of  guiding  the  KA 
tool  through  all  the  stages  (retrieval,  mapping,  and  adaptation),  the  analogy  can  be  as  far  fetched 
as  the  user  finds  suitable.  For  example,  one  can  imagine  using  the  plan  to  check  if  a  ship  fits 
in  a  port  to  check  if  an  event  happens  during  another  one  by  checking  if  the  corresponding  lime 
intervals  til  within  one  another.  Thus,  the  same  general  mechanism  can  be  used  throughout  any 
stage  of  knowledge  acquisition  and  throughout  any  application  domain  at  hand.  Notice  that  this 
requires  that  knowledge  acquisition  does  not  happen  in  a  vacuum,  and  by  that  we  mean  that  the 
system  should  have  access  to  as  many  knowledge  bases  in  different  domains  as  possible.  Some 
efforts  in  very  large  knowledge  ba.ses  already  aim  in  this  direction  [Neches  et  ai,  1991 ;  Lenat  and 
Guha,  I989J.  This  is  much  as  humans  communicate  and  learn  things  from  each  other:  by  first 
establishing  backgrounds  and  then  using  constructs  that  the  other  person  is  accustomed  to.  For 
example,  doctors  may  not  teach  new  things  to  biologists  in  the  same  way  that  they  would  explain 
them  to  engineers,  since  they  would  have  common  ground  concepts  with  the  former  to  build  upon. 
Having  knowledge  bases  shared  by  different  knowledge-based  systems  will  some  day  provide  this 
common  ground  for  our  knowledge  acquisition  tools. 


5  Next  Step:  Generalization  of  Problem-Solving  Methods 

Of  course,  acquiring  knowledge  by  analogy  has  its  limits.  For  example,  a  user  who  is  entering 
knowledge  in  a  medical  domain  may  not  know  in  detail  what  problem-solving  knowledge  is 
involved  in  our  transportation  domain.  This  is  also  common  in  humans:  the  more  we  know  about 
the  other  person’s  areas  of  knowledge,  the  easier  it  is  to  explain  things  to  them.  Again,  we  can 
turn  to  machine  learning  techniques  for  an  answer.  This  section  describes  our  plans  for  future 
work  regarding  the  use  of  generalization  and  induction  techniques  to  extend  the  current  analogical 
reasoning  in  EXPECT. 

Let  us  consider  an  example  from  our  transportation  domain.  There  is  a  plan  to  calculate  the 
throughput  (takeoffs  per  day)  that  an  airport  can  handle.  To  do  that,  the  given  throughput  is  adjusted 
by  a  percentage  factor  determined  by  the  presence  of  bad  weather,  and  by  how  many  docks  are 
available  for  unloading.^  There  is  also  a  different  plan  to  calculate  how  many  planes  are  available 
for  a  transportation  problem.  To  do  so,  the  amount  of  planes  assigned  for  the  task  is  adjusted  by  a 
percentage  factor  that  takes  into  account  the  rate  at  which  each  type  of  plane  tends  to  break  down 
and  how  much  time  it  takes  to  repair  it.  Induction  techniques,  and  in  particular,  generalization  from 
examples  could  be  extended  and  applied  in  these  cases  to  provide  the  system  with  the  concept  of 
a  plan  to  do  adjustments  of  values,  as  shown  in  Figure  8.  The  following  example  illustrates  how 
these  generalized  plans  could  be  used  to  cooperate  with  an  expert  during  KA. 

In  summary,  this  scenario  illustrates  how  expect  could  use  plan  generalization  and  analogical 
reasoning  to  guide  knowledge  acquisition.  The  knowledge  about  adjustments  in  the  transportation 
domain  is  used  to  acquire  adjustments  for  drug  therapy.  We  used  two  very  different  domains  to 
illustrate  the  potential  of  this  approach,  but  the  impact  should  be  greater  when  the  nature  of  the 
domains  is  not  so  diverse. 

Suppose  that  a  medical  expert  is  using  expect  for  administering  drugs,  in  particular  to  advice 
with  digitalis  therapy  [Swartout,  1983].  The  default  dose  of  a  drug  has  to  be  reduced  if  the  patient 


^If  there  are  not  enough  unloading  docks  the  planes  would  be  idle  waiting  for  a  dock  to  become  available. 
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Figure  8:  A  hierarchy  of  plans  for  adjusting  values. 


has  certain  conditions  (called  sensitivities  to  the  drug).  To  treat  a  patient  with  digitalis,  the  normal 
dose  (1  /Jg/Kg)  needs  to  be  adjusted  by  a  factor  of  0.8  if  the  patient  has  a  high  level  of  serum 
calcium  and  by  a  factor  of  0.7  when  serum  potassium  is  low.  If  both  sensitivities  are  present,  the 
default  dose  is  adjusted  by  the  product  of  both  factors  (0.8  +  0.7). 

Suppose  now  that  the  system  knows  only  about  one  sensitivity  (low  serum  potassium),  as  well  as  , 

how  to  adjust  the  dose  of  digitalis  if  the  patient  has  this  condition.  Figure  9  shows  a  scenario  where 
the  user  wants  to  add  a  new  sensitivity;  high  serum  calcium.  The  user  enters  whatever  information 
she  is  aware  that  the  system  needs  about  drug  sensitivities  in  line  [  1 J.  EXPECT  updates  the  domain 
model  accordingly.  Now  EXPECT  examines  the  problem-solving  knowledge  to  determine  what 
sensitivities  are  used  for.  This  causes  the  question  in  line  [2]  of  how  to  adjust  the  dose  for  this  new  ^ 

sensitivity. 

The  system  knows  to  acquire  an  adjustment  for  this  sensitivity  based  on  how  sensitivities  are 
used  for  problem  solving.  Because  a  general  plan  for  doing  adjustments  is  available,  the  system 
knows  that  when  more  than  one  adjustment  is  present  it  needs  a  method  to  recombine  the  results 
(line  [6]).  The  system  could  justify  the  reason  for  the  questions  to  the  user  (lines  [7-8]),  as  well  I 

as  to  produce  examples  that  undo  the  generalization  and  facilitate  a  ground  analogy  to  the  user  in 
terms  of  airport  takeoffs  (line  [  lOj). 

This  example  illustrates  how,  through  plan  generalization,  the  system  could  further  support 
analogies  across  domains.  The  generalization  hierarchy  would  provide  the  grounds  for  transferring 
knowledge  across  different  domains  through  its  abstraction  from  domain-specific  knowledge.  The  ^ 

type  of  language  that  we  use  in  EXPECT’s  plans  combined  with  the  LOOM  knowledge  representation 
system  would  facilitate  this,  but  in  addition  we  plan  to  research  on  general-purpose  machine 
learning  methods  to  induce  these  generalized  plans  automatically  or  semi-automatically.  In  the 
later  case,  a  knowledge  engineer  would  be  involved,  but  we  believe  this  is  a  much  lighter  burden 
than  other  current  KA  environments  would  impose.  Either  way,  these  machine  learning  methods  g 

could  prove  more  useful  for  automating  KA  than  a  general  KA  tool  for  a  particular  generic  method. 
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U:  Add  a  new  sensitivity  for  digitalis:  high  serum  calcium. 

S:  Ok.  What  method  should  I  use  to  adjust  the  dose  for  high  serum  calcium 
sensitivity  [Take  percentage;  Do  computation;  Other]? 

U;  Take  percentage 

S:  Ok.  Which  percentage? 

U:  0.8 

S:  Ok.  Now  1  need  to  know  how  to  combine  the  results  of  the  adjustments. 
Choose  one  of  (MIN;MAX;ADD;MULTIPLY;Other]. 

U:  Why? 

S;  We  are  adjusting  digitalis  dose.  To  do  an  adjustment,  I  need  to  know;  (1) 
value  to  be  adjusted,  (2)  factors,  (3)  methods  to  adjust  the  value,  and  (4)  how 
to  combine  the  results.  In  this  case,  (1)  digitalis  dose  (2)  drug  sensitivities  (3) 
take  percentage  0.8  for  high  serum  calcium,  take  percentage  0.7  for  low  serum 
potassium.  Now  I  need  to  know  (4)  how  to  combine  the  results. 

U;  How  to  combine  the  results? 

S:  For  example,  when  I  compute  the  takeoffs  per  day  in  an  airport,  I  adjust  the 
default  value  of  takeoffs  for  the  airport  according  to  weather  conditions  and 
to  available  unloading  docks.  To  do  an  adjustment,  I  need  to  know;  (1 )  value 
to  be  adjusted,  (2)  factors,  (3)  methods  to  adjust  the  value,  and  (4)  how  to 
combine  the  results.  In  this  case,  (1)  takeoffs  per  day  (2)  weather,  unloading 
docks  (3)  take  percentage,  compute  docks  throughput  (4)  take  minimum  value. 
In  the  digitalis  dose  adjustment,  I  need  to  know  how  to  combine  the  results  of 
the  adjustments.  Choose  one  of  (MIN;MAX;ADD;MULTIPLY;Other]. 

U:  multiply 

S:  Ok.  High  serum  calcium  is  now  a  new  sensitivity  for  digitalis. 

Figure  9:  Hypothetical  scenario:  Adding  new  plans  in  a  different  domain. 
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6  Related  Work 

• 

NeoDisciple  [Tecuci,  1992]  integrates  several  machine  learning  techniques  in  a  knowledge  acqui¬ 
sition  tool.  NeoDisciple  takes  a  user-given  answer  to  a  problem  and  applies  explanation-based 
learning  to  build  a  plausible  proof  tree,  abduction  to  complete  the  proof,  and  several  other  learning 
techniques  to  generalize  the  proof.  Its  predecessor,  disciple  [Tecuci  and  Kodratoff,  1990],  built  an 

•  analogy  with  an  existing  proof  when  the  system  lacked  domain  knowledge  to  build  the  proof  for 
a  new  input.  Our  approach  automates  different  parts  of  the  analogical  process.  The  user  suggests 
the  source  of  the  analogies,  the  mapping,  and  any  necessary  adaptations.  The  tool  provides  the 
supporting  environment  by  navigating  through  the  system’s  reasoning  and  carrying  out  the  user’s 
corrections  through  analogical  reasoning.  EXPECT  provides  a  framework  for  analogical  reasoning 

•  where  the  tool  takes  responsibility  for  suggesting  corrections  and  for  making  the  adequate  changes 
in  the  knowledge  base. 

Other  work  on  analogy  uses  the  derivational  traces  of  the  problem  solver  to  guide  the  system 
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in  solving  a  new  problem  [Veloso,  1992;  Carbonell,  1986].  EXPECT  uses  the  design  history  as  a 
source  of  analogies  as  well,  and  its  problem  solver  will  find  plans  to  match  any  new  goals  that 
arise  as  a  result  of  the  mapping.  However,  the  crucial  difference  is  that  EXPECT  will  create  new 
problem-solving  knowledge  when  no  plan  is  found  to  achieve  a  goal.  A  new  rule  is  created  in  our 
first  scenario  to  compute  the  maximum  depth  of  a  berth,  without  which  the  system  could  not  have 
solved  the  problem.  In  other  words,  expect  is  learning  at  the  knowledge  level  [Newell,  1982]. 

The  Spark/Bum/FireFighter  framework  [Klinker  et  ai,  1991]  treats  knowledge  acquisition 
as  a  programming  effort,  and  aims  to  provide  a  set  of  mechanisms  as  basic  blocks  for  building 
knowledge-based  systems.  The  goal  is  to  design  such  mechanisms  to  be  both  usable  (understand¬ 
able  by  domain  experts)  and  reusable  (applicable  to  several  tasks  and  domains).  The  PROTEGE-n 
system  [Puertae/a/.,  1992]  is  also  based  on  reusable  mechanisms  as  building  blocks  for  knowledge 
acquisition,  and  addresses  usability  by  integrating  domain-dependent  knowledge  in  the  process  of 
putting  these  mechanisms  together.  EXPECT  shares  both  goals,  and  the  aim  is  to  achieve  them 
without  explicitly  building  such  mechanisms.  If  at  all,  these  mechanisms  would  be  a  by-product 
of  the  tool’s  interaction  with  the  u.ser  and  its  learning  capabilities.  Problem-solving  knowledge  in 
EXPECT  is  usable  because  it  is  accessible  to  domain  experts  through  explanations.  Knowledge  is 
reused  when  the  user  proposes  analogies  with  new  situations,  as  well  as  through  any  generalizations 
over  existing  cases. 

Another  general-purpose  knowledge  acquisition  approach  is  that  propo.sed  by  KADS  j  Wielingaet 
ai,  1 992],  a  methodology  for  building  knowledge  based  systems,  which,  unlike  EXPECT,  emphasizes 
the  initial  building  of  a  system  (as  oppo.sed  to  its  refinement).  KADS  views  knowledge  acquisition 
as  a  modelling  activity  and  propo.ses  a  number  of  models  that  a  knowledge  engineer  needs  to 
build.  Each  model  emphasizes  a  specific  aspect  of  the  system  to  construct  and  contains  part  of  the 
knowledge  needed.  kaDS  also  separates  the  domain  model  from  the  control  knowledge,  which  is 
in  turn  divided  into  the  inference  model,  the  ta.sk  model,  and  the  .strategic  knowledge.  These  last 
three  models  together  indicate  how  knowledge  from  the  domain  model  is  to  be  u.sed  in  problem 
.solving,  and  could  thus  theoretically  be  also  u.sed  to  guide  refinement  of  a  knowledge-based  system 
once  an  initial  prototype  has  been  built.  This  is  not  currently  done,  however.  Kads’s  current  aim 
is  to  help  the  knowledge  engineer  faced  with  the  task  of  building  a  new  knowledge-based  system 
by  providing  an  explicit  .set  of  building  blocks  (or  models)  that  the  knowledge  engineer  .should  be 
concerned  about,  thus  using  a  divide-and-conquer  approach  to  the  initial  knowledge  acquisition 
task.  Our  aim  in  EXPECT  is  a  complementary  one;  it  is  to  aid  in  refining  and  debugging  a  knowledge- 
based  system  automatically  once  a  prototype  system  exists.  Because  EXPECT  derives  code  from  the 
specification  automatically  (i.e.,  the  domain  model  and  the  plans),  changes  done  at  the  specification 
level  are  automatically  reflected  in  the  executable  code.  In  contrast,  until  executable  systems  are 
automatically  derived  from  the  models  designed  with  the  KADS  methodology,  guidance  from  the 
models  would  only  apply  to  refining  the  models  themselves.  The  changes  would  then  need  to  be 
reflected  in  the  code  by  hand. 


7  Conclusion 

We  have  shown  our  approach  to  building  KA  tools  to  achieve  knowledge  re-use  based  on  general- 
purpose  machine  learning  methods.  In  particular,  we  showed  how  a  learning  by  analogy  mechanism 
can  be  incorporated  in  a  knowledge  acquisition  tool  to  facilitate  the  knowledge  acquisition  process. 


In  our  system,  the  current  content  of  the  knowledge  base  is  used  to  create  expectations  dynamically 
for  what  knowledge  is  to  be  acquired.  These  expectations  are  based  on  the  functionality  of  each 
piece  of  knowledge  in  the  overall  system,  and  on  analogies  derived  from  the  current  knowledge 
base.  Importantly,  the  system  and  the  user  work  in  synergy;  unlike  other  machine  learning 
approaches,  our  system  does  not  attempt  to  deduce  all  the  information  needed  to  form  the  analogy 
by  it.scif.  Rather,  it  relies  on  input  from  the  user  to  guide  its  analogieal  learning.  On  the  other  hand, 
the  user  does  not  need  to  know  a  lot  about  the  knowledge  base  or  to  enter  all  the  new  necessary 
information  explicitly,  but  can  rely  on  the  tool  to  guide  to  process.  We  showed  how  this  approach 
can  be  employed  to  acquire  information  both  within  a  domain  and  across  domains. 

We  also  outlined  how  other  general  learning  mechanisms  (such  as  generalization  and  induction 
techniques)  might  be  incorporated  into  our  system.  We  hope  to  support  with  this  work  our  claim 
that  powerful,  versatile  and  yet  practical  knowledge  acquisition  tools  can  be  built  by  coupling 
general  machine  learning  mechanisms  with  more  traditional  knowledge  acquisition  techniques. 
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